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Abstract 


This memo presents specific implementation guidelines for running 
RSVP over ATM switched virtual circuits (SVCs). The general problem 
is discussed in [6]. Implementation requirements are discussed in 
[2]. Integrated Services to ATM service mappings are covered in [3]. 
The full set of documents present the background and information 
needed to implement Integrated Services and RSVP over ATM. 


1. Introduction 


This memo discusses running IP over ATM in an environment where SVCs 
are used to support QoS flows and RSVP is used as the internet level 
QoS signaling protocol. It applies when using CLIP/ION, LANE2.0 and 
MPOA methods for supporting IP over ATM. The general issues related 
to running RSVP[4] over ATM have been covered in several papers 
including [6] and other earlier work. This document is intended as a 
companion to [6,2] and as a guide to implementers. The reader should 
be familiar with both documents. 


This document provides a recommended set of functionality for 
implementations using ATM UNI3.x and 4.0, while allowing for more 
sophisticated approaches. We expect some vendors to additionally 
provide some of the more sophisticated approaches described in [6], 


and some networks to only make use of such approaches. The 
recommended set of functionality is defined to ensure predictability 
and interoperability between different implementations. Requirements 


for RSVP over ATM implementations are provided in [2]. 
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This document uses the same terms and assumption stated in [2]. 
Additionally, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in RFC 
2119 [5]. 


2. Implementation Recommendations 


This section provides implementation guidelines for implementation of 
RSVP over ATM. Several recommendations are common for all, RSVP 
sessions, both unicast and multicast. There are also recommendations 
that are unique to unicast and multicast session types. 


2.1 RSVP Message VC Usage 


The general issues related to which VC should be used for RSVP 
messages is covered in [6]. It discussed several implementation 
options including: mixed control and data, single control VC per 
session, single control VC multiplexed among sessions, and multiple 
VCs multiplexed among sessions. QoS for control VCs was also 
discussed. The general discussion is not repeated here and [6] 
should be reviewed for detailed information. 


RSVP over ATM implementations SHOULD send RSVP control (messages) 
over the best effort data path, see figure 1. It is permissible to 
allow a user to override this behavior. The stated approach 
minimizes VC requirements since the best effort data path will need 
to exist in order for RSVP sessions to be established and in order 
for RSVP reservations to be initiated. The specific best effort 
paths that will be used by RSVP are: for unicast, the same VC used to 
reach the unicast destination; and for multicast, the same VC that is 
used for best effort traffic destined to the IP multicast group. 

Note that for multicast there may be another best effort VC that is 
used to carry session data traffic, i.e., for data that is both in 
the multicast group and matching a sessions protocol and port. 
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Figure 1: RSVP Control Message VC Usage 


The disadvantage of this approach is that best effort VCs may not 
provide the reliability that RSVP needs. However the best effort 
path is expected to satisfy RSVP reliability requirements in most 
networks. Especially since RSVP allows for a certain amount of packet 
loss without any loss of state synchronization. 


2.2 Aggregation 


As discussed in [6], data associated with multiple RSVP sessions can 
be sent using the same shared VCs. Implementation of such 
"aggregation" models is still a matter for research. Therefore, RSVP 
over ATM implementations SHOULD use independent VCs for each RSVP 
reservation. 


2.3 Short-Cuts 


Short-cuts allow ATM attached routers and hosts to directly establish 
point-to-point VCs across LIS boundaries, i.e., the VC end-points are 
on different IP subnets. Short-cut support for unicast traffic has 
been defined in [7] and [1]. The ability for short-cuts and RSVP to 
interoperate has been raised as a general question. The area of 
concern is the ability to handle asymmetric short-cuts. Specifically 
how RSVP can handle the case where a downstream short-cut may not 
have a matching upstream short-cut. In this case, which is shown in 
figure 2, PATH and RESV messages following different paths. 
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Figure 2: Asymmetric RSVP Message Forwarding With ATM Short-Cuts 


Examination of RSVP shows that the protocol already includes 
mechanisms that allows support of the asymmetric paths. The 
mechanism is the same one used to support RESV messages arriving at 
the wrong router and the wrong interface. RSVP messages are only 
processed when they arrive at the proper interface. When messages 
arrive on the wrong interface, they are forwarded by RSVP. The 
proper interface is indicated in the NHOP object of the message. So, 
existing RSVP mechanisms will support the asymmetric paths that can 
occur when using short-cuts. 


The short-cut model of VC establishment still poses several issues 
when running with RSVP. The major issues are dealing with established 
best effort short-cuts, when to establish short-cuts, and QoS only 
short-cuts. These issues will need to be addressed by RSVP 
implementations. 


The key issue to be addressed by RSVP over ATM implementations is 
when to establish a short-cut for a QoS data flow. RSVP over ATM 
implementations SHOULD simply follow best effort traffic. When a 
short-cut has been established for best effort traffic toa 
destination or next-hop, that same end-point SHOULD be used when 
setting up RSVP triggered VCs for QoS traffic to the same destination 
or next-hop. This will happen naturally when PATH messages are 
forwarded over the best effort short-cut. Note that in this 
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approach, when best effort short-cuts are never established, RSVP 
triggered QoS short-cuts will also never be established. 


2.4 Data VC Management for Heterogeneous Sessions 


Heterogeneous sessions can only occur with multicast RSVP sessions. 
The issues relating to data VC management of heterogeneous sessions 
are covered in detail in [6] and are not repeated in this document. 
In summary, heterogeneity occurs when receivers request different 
levels of QoS within a single session and also when some receivers do 


not request any QoS. Both types of heterogeneity are shown in figure 
3. 
+----+ 
+------ > | R1 | 
+----+ 
| +----+ 
+----- + ----—- + +=—> | R2 | 
| | --------- + +----+ Receiver Request Types: 
| sre | ----> QoS 1 and QoS 2 
| [It aneian + +----+ ....> Best-Effort 
+----- E epou + +..> | R3 | 
+----+ 
/\ 
| t----+ 
Lill Ea > | R4 | 
[1 +----+ 
Single 
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Group 


Figure 3: Types of Multicast Receivers 


[6] provides four models for dealing with heterogeneity: full 
heterogeneity, limited heterogeneity, homogeneous, and modified 
homogeneous models. The key issue to be addressed by an 
implementation is providing requested QoS downstream. One of, or some 
combination of, the discussed models [6] may be used to provide the 
requested QoS. Unfortunately, none of the described models is the 
right answer for all cases. For some networks, e.g. public WANs, it 
is likely that the limited heterogeneous model or a hybrid limited- 
full heterogeneous model will be desired. In other networks, e.g. 
LANs, it is likely that a the modified homogeneous model will be 
desired. 
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Since there is not one model that satisfies all cases, 
implementations SHOULD implement one of either the limited 
heterogeneity model or the modified homogeneous model. 
Implementations SHOULD support both approaches and provide the 
ability to select which method is actually used, but are not required 
to do so. 


3. Security Considerations 


The same considerations stated in [4] and [8] apply to this document. 
There are no additional security issues raised in this document. 
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Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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